Initiating peer-to-peer tunnels

ABSTRACT

Initiating peer-to-peer tunnels between clients in a mobility domain. Client traffic in a mobility domain normally passes from the initiating client to an access node, and from the access node through a tunnel to a controller, and then through another tunnel from the controller to the destination access node, and the destination client. When initiated by the controller, the access nodes establish a peer-to-peer tunnel for suitable client traffic, bypassing the “slow” tunnels through the controller with a “fast” peer-to-peer tunnel. Traffic through this “fast” tunnel may be initiated once the tunnel is established, or traffic for the “fast” tunnel may be queued up until traffic has completed passing through the “slow” tunnel.

BENEFIT CLAIM; INCORPORATION BY REFERENCE; RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No.13/233,976 filed on Sep. 15, 2011, which is a continuation of U.S.application Ser. No. 12/433,610, filed on Apr. 30, 2009. The presentapplication is related to U.S. patent application Ser. No. 12/429,981filed on Apr. 24, 2009. All of the aforementioned patent applicationsare hereby incorporated by reference.

The applicant(s) hereby rescind any disclaimer of claim scope in theparent application(s) or the prosecution history thereof and advice theUSPTO that the claims in this application may be broader than any claimin the parent application(s).

BACKGROUND OF THE INVENTION

The present invention relates to digital networks, and in particular, tothe problem of initiating traffic in peer-to-peer tunnels in switcheddigital systems.

Modern digital networks operating under IEEE 803.2 and 802.11 standardsare called upon to support a wide range of wired and wireless clients.

Traffic between clients in a mobility domain typically passes from theoriginating client to an access node, and then from the access node to acontroller through a tunnel. The traffic then passes through anothertunnel from the controller to the destination access node, and to thedestination client. Traffic passing through the controller may besubject to firewalling, deep packet inspection, authentication, andsimilar processes.

These processes, and the trip from one access node to another throughthe controller take time, particularly when the controller and theaccess nodes may not reside in the same building, or even the samegeneral locale. Properly authenticated traffic may be eligible forpeer-to-peer forwarding. In peer-to-peer forwarding, as described inU.S. patent application Ser. No. 12/429,981 titled “Peer-to-PeerForwarding for Packet-Switched Traffic” filed Apr. 24, 2009, andincorporated by reference herein, a tunnel is established between thetwo access nodes, and traffic sent through this peer-to-peer tunnel.

Visualizing the peer-to-peer tunnel as a short, fast pipe, and thecontroller-terminated tunnels as a long, slow pipe, the transition oftraffic from the slow pipe to the fast pipe may result in issues such asout-of-order arrival of packets, with fast pipe packets arriving at thedestination before packets already in the slow pipe. While someapplications may not be affected by such out-of-order arrival, otherapplications such as multimedia are affected, resulting in, for example,stuttered or dropped audio and/or video.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may be best understood by referring to the followingdescription and accompanying drawings that are used to illustrateembodiments of the invention in which:

FIG. 1 shows a network,

FIG. 2 shows details of network devices,

FIG. 3 shows tunnels in a network,

FIG. 4 shows an additional network, and

FIG. 5 shows queued startup in a network.

DETAILED DESCRIPTION

Embodiments of the invention relate to methods of initiating tunnelingtraffic in a digital network. A digital network has one or more centralcontrollers to which a plurality of access nodes are connected. Eachaccess node provides a combination of wireless and/or wired access toresources available through the central controller. The access nodes maybe directly connected to the controller, or they may connect to thecontroller through routed networks such as a corporate Intranet, widerInternet, through private networks such as VPNs, or through acombination of wired and wireless backhaul.

In operation, the access nodes establish communications with thecontroller using tunnels. An example of a tunnel is a GRE tunnel.Traffic to and from clients connected to an access node is routedthrough the tunnel and through the central controller to which theaccess node is connected.

A mobility controller process runs in the controller, monitoring trafficto and from clients. The set of access nodes known to the controller andother associated controllers is defined as the mobility domain. When themobility controller recognizes that traffic is being sent from a firstclient in the mobility domain to a second client in the mobility domain,the mobility controller evaluates whether the traffic is eligible forpeer-to-peer forwarding. If the traffic is eligible for per-to-peerforwarding, the mobility manager instructs the access node to which thefirst client is connected to establish a peer-to-peer tunnel to theaccess node to which the second client is connected, and to direct thetraffic through the peer-to-peer tunnel.

In accordance with the invention, traffic through the peer-to-peertunnel may begin flowing as soon as the peer-to-peer (“fast”) tunnel isestablished, or traffic in one or both directions through the tunnel maybe queued until traffic flowing through the controller-terminated(“slow”) tunnels has completed.

Completion of slow traffic through the controller-terminated tunnels maybe sensed in a number of ways. Slow tunnel traffic may be timed out, andqueued traffic released after a preset time since the last packet wassent through the slow tunnel. The identity of the last packet sentthrough the slow tunnel may be retained, and queued traffic releasedwhen an acknowledgement for that packet is received. A special packetmay be sent through the slow tunnel and queued traffic released when anacknowledgement for that packet is received.

FIG. 1 shows a digital network. Router 100 connects to a network, notshown. Router 100 also provides services to controller 200. Controller200 has a plurality of ports, 230 a, 230 b for supporting devices suchas access nodes 400 a, 400 b, 400 c, 400 d.

As shown in FIG. 1, these ports 120 a, 120 b connect through switchednetwork 290 to routers 300 a and 300 b.

Access nodes 400 a, 400 b, 400 c, 400 d provide wireless and possiblywired services to clients. As shown in FIG. 1, wireless client 500 a isconnected to access node 400 a. Access node 400 b supports wirelessclient 500 b and wired client 510 b. Access node supports wirelessclient 500 c.

As shown in FIG. 2, controllers 200 are a purpose-built digital deviceshaving a CPU 210, memory hierarchy 220, and a plurality of networkinterfaces 230. CPU 210 may be a MIPS-class processor from companiessuch as Raza Microelectronics or Cavium Networks, although CPUs fromcompanies such as Intel, AMD, IBM, Freescale, or the like may also beused. Memory hierarchy 220 includes read-only memory for device startupand initialization, high-speed read-write memory such as DRAM forcontaining programs and data during operation, and bulk memory such ashard disk or compact flash for permanent file storage of programs anddata. Network interfaces 230 are typically IEEE 802.3 Ethernetinterfaces to copper, although high-speed optical fiber interfaces mayalso be used. Controller 200 typically operates under the control ofpurpose-built embedded software, typically running under a Linuxoperating system, or an operating system for embedded devices such asVXWorks. Controller 200 may have dedicated hardware for encryption,and/or for routing packets between network interfaces 230.

Similarly, as understood by the art, access nodes 400 a, 400 b, 400 cand 400 d, are also purpose-built digital devices. These access nodesinclude CPU 410, memory hierarchy 420, wired interface 430, and wirelessinterface 440. As with controller 200, the CPU commonly used for suchaccess nodes is a MIPS-class CPU such as one from Raza Microelectronicsor Cavium Networks, although processors from other vendors such asIntel, AMD, Freescale, and IBM may be used. The memory hierarchycomprises read-only storage for device startup and initialization, fastread-write storage such as DRAM for holding operating programs and data,and permanent bulk file storage such as compact flash. Wireless accessnodes 300 typically operate under control of purpose-built programsrunning on an embedded operating system such as Linux or VXWorks.Wireless interface 340 is typically an interface operating to the familyof IEEE 802.11 standards including but not limited to 802.11a, b, g,and/or n. Multiple wired interfaces 430 may be provided, with one wiredinterface 430 a being used to connect the access node to its controller,and the other wired interfaces 430 b used to host wired devices asclients. While wired interfaces such as 802.3 Ethernet may be used, USBmay also be used to support printers, mass storage devices, and wirelessback-haul links such as 3G or WiMAX modems.

While FIGS. 1 and 2 depict a wired backhaul connecting access nodes 400to controller 200, a combination of wired and wireless backhauls mayalso be used, for example, using WiMAX, 3G, or other high-speed wirelessconnections. While a wired connection to a modem such as an ADSL modemor a cable modem may be used, such a modem may also be built into accessnode 400.

Routers 300 are also purpose-built digital devices, and similar tocontroller 200, they contain a CPU, memory hierarchy, and a plurality ofinterfaces. Routers typically run dedicated software devoted to thetasks required. Routers are commercially available from a number ofcompanies such as Cisco-Linksys, Hewlett Packard, D-Link, and others.

Wireless clients 500 are also digital devices, similarly having CPU 510,memory hierarchy 520, wireless interface 530, and I/O devices 540. Asexamples, wireless device 500 may be a general purpose computer such asa laptop, or may be a purpose-built device such as a Wi-Fi phone or ahandheld scanner. In a general-purpose computer, CPU 510 may be aprocessor from companies such as Intel, AMD, Freescale, or the like. Inthe case of purpose-built devices, Acorn or MIPS class processors may bepreferred. Memory hierarchy 520 comprises the similar set of read-onlymemory for device startup and initialization, fast read-write memory fordevice operation and holding programs and data during execution, andpermanent bulk file storage using devices such as flash, compact flash,and/or hard disks. Additional I/O devices 540 may be present, such askeyboards, displays, speakers, barcode scanners, and the like.

In operation and as shown in FIG. 3, access nodes 400 a, 400 b, 400 c,400 d establish communications with controller 200, in the case of FIG.3, through routers 300 and switched network 200. As shown for accessnodes 400 a and 400 b, tunnels 600 a, 600 b such as GRE tunnels areestablished between the access node and controller 200. Such tunnels 600a, 600 b may be established on a per-access node basis, or on a pernetwork basis, with one tunnel established for each advertised wirelessnetwork (BSSD) or one tunnel established for each wired port on anaccess node.

Assume wireless client 500 a is connected to access node 400 a, andclient 500 b is connected to access node 400 b. When client 500 aestablishes a connection to client 500 b, traffic from client 500 apasses through access node 400 a, tunnel 600 a, to controller 200.Controller 200 identifies the traffic destination as client 500 b, andsends the traffic though tunnel 600 b to access node 400 b and client500 b.

This routing is performed by controller 200 using the IP addresses ofclients 500 a and 500 b, as well as the MAC (media access controller)addresses of clients 500 a, 500 b and access nodes 400 a and 400 b. Whenclient 500 a wishes to send data to client 500 b, it in essence forms anIP packet with client 500 b's IP address as the destination, and withclient 500 a's IP address and MAC address as the source. Thisinformation is encapsulated and sent to controller 200.

Controller 200 keeps tables of all access nodes it controls, and allclients associated with those nodes, including IP and MAC addresses. Inthis way, when it examines the packet from client 500 a, it candetermine that client 500 b, the destination, is connected to accessnode 400 b, and direct the traffic through tunnel 600 b to that accesspoint, and the destination device.

Even if clients 500 a and 500 b are sitting in the same office suite,ten meters apart, traffic between them is routed through controller 200.

Mobility manager 280 is a process running in controller 200. Byaccessing controller 200's tables of access nodes and their clients,mobility manager 280 can detect when a client is exchanging data withanother client in its mobility domain.

As shown in FIG. 4, when mobility manager 280 detects that client 500 ais communicating with client 500 b, also in the mobility domain ofcontroller 200, mobility manager 280 evaluates if this traffic iseligible for peer-to-peer forwarding. If the traffic is eligible forpeer-to-peer forwarding, mobility manager 280 instructs access node 400a to establish peer-to-peer tunnel 610 between access node 400 a andaccess 400 b, and to route that traffic between clients 500 a and 500 bthrough tunnel 610 rather than through tunnel 600 a. While thepeer-to-peer tunnel is being established, traffic between clients flowsthrough the controller. In this manner traffic between clients 500 a and500 b rather than traveling through tunnels 600 a and 600 b andcontroller 200, instead travels through tunnel 610 once the tunnel isestablished.

A peer-to-peer tunnel may be established any time mobility manager 280detects connections and data exchanges between clients in its mobilitydomain. Or, peer-to-peer tunnels may be evaluated and only establishedon an authenticated basis according to pre-established rules.Peer-to-peer tunnels may be limited by client identity, including butnot limited to client IP address, client MAC address, clientauthentication, and the like, destination identity, port, traffic type,and so on. As an example, assume a high-speed printer is connected as aclient to access node 400 a. Appropriate rules for the establishment ofpeer-to-peer tunnels for a printer would be limited to ports andprotocols needed for printer use for local authorized users, with noaccess allowed for guests. Similarly, traffic to e-mail servers wouldnot be eligible for peer-to-per forwarding, so that such traffic wouldalways pass through controller 280 and be subject to firewalling, virusdetection, deep packet inspection, and the like. As another example,network time protocol traffic on port 123 would be eligible forpeer-to-peer forwarding to reduce transit delays for time data.

It should be understood that which end of the traffic causes the tunnelto be established is immaterial. As an example, consider a user sendingqueries to a remote database server. It does not matter if the traffictriggering the formation of a peer-to-peer tunnel is the transmission ofa query from the client to the database server, or the transmission ofthe query result from the database server to the client.

Peer-to-peer tunnels may be established on a session basis, or may beaged. As an example, for a device such as a high-speed printer, apeer-to-peer tunnel with a timeout of thirty seconds may be appropriate;if no activity passes through the tunnel for that predetermined periodof time, the tunnel is discontinued. If bursts of traffic between twoclients exceed the time-out period, the peer-to-peer tunnel will bediscontinued, but the next traffic between the clients, which will oncemore be routed through controller 200, causes the peer-to-peer tunnel tobe re-established.

Assume as an example file/database server 510 b is connected via a wiredconnection to access node 400 b. Peer-to-peer tunnels may be permittedfor authorized users of the database for the specific protocols andports used for database access, with all other traffic routed throughcontroller 200 for filtering, firewalling, and authentication. As anexample, while database traffic using port 3306 between server 510 b andclient 500 a may be routed through a peer-to-peer tunnel 610, traffic onport 80 between client 500 a and server 510 b is still routed initiallythrough controller 200.

When multiple controllers 200 are present within a mobility domain,mobility managers 280 operating in each controller may cooperate insupporting peer-to-peer tunneling within the mobility domain. In oneembodiment, a mobility manager 280 broadcasts updates of connectedclients to other mobility managers in the mobility domain. These updatesmay be made on a periodic basis, may be event-driven, such as on clientconnection or disconnection, or on a combination. By providing theability for a mobility manager to identify clients attached to adifferent controller that are still within the mobility domain,peer-to-peer forwarding may be extended to cross controller boundaries.

In another embodiment involving multiple controllers, mobility managers280 may send queries to other mobility managers within the domain toinquire if a destination is a client of another mobility manager withinthe mobility domain. It may be useful in some embodiments to applyadditional authentication when controller boundaries are crossed. As anexample, consider an enterprise network spread over many locations,perhaps over many time zones. While establishing a peer-to-peer tunnelbetween a streaming media device such as a security webcam and amonitoring station offloads that streaming traffic from passing throughthe controller, other policies may wish to restrict access to suchcameras to only users connected to the controller at the particularsite, not allowing access across controller boundaries, or only allowingaccess across controller boundaries to certain classes of users.

Assume for example that client 500 a of FIG. 4 is receiving a videostream from a wireless camera 500 b. Initially this traffic will berouted through controller 200 via tunnels 600 b and 600 a. Assuming thistraffic is eligible for per-to-peer forwarding, tunnel 610 isestablished for this traffic between wireless camera 500 b and client500 a.

Visualizing tunnels 600 b and 600 a as a slow pipe, and tunnel 610 as afast pipe, fast pipe traffic from camera 500 b could arrive atdestination 500 a while a large number of packets from camera 500 b arestill in the slow pipe. These packets from the slow pipe will continueto arrive at destination 500 a, even though subsequent packets havealready arrived. Many video clients respond to this out-of-order arrivalby dropping the old, out-of-order packets, which can result in stutteredor jittery images.

For other types of traffic, for example the retrieval of large amountsof data from a database, out-of-order delivery may not be an issue.

According to the invention, peer-to-peer tunnel traffic may begin assoon as the tunnel is established, or traffic for the peer-to-peertunnel may be queued until traffic has completed flowing through thecontroller-terminated “slow” tunnel. This queue and release model may beapplied bidirectionally or unidirectionally.

As shown in FIG. 5, if queuing is indicated, packets for thepeer-to-peer tunnel are placed 460 in a queue 450 in the access node.This queue is released, and packets sent 470 through the peer-to-peertunnel in a first-in-first-out fashion once traffic through the slowtunnel, in this example 600 b and 600 a, has completed.

According to the invention there are a number of ways to determine thatall traffic sent through the slow tunnel (tunnels 600 b 600 a) hasarrived.

A special packet may be sent through the slow tunnel; the queue isrelease when an ACK is received from the destination, indicating thespecial packet has arrived.

The identification of the last packet sent through the slow tunnel maybe kept, and the queue released when an ACK is received from thedestination indicating that this packet has arrived.

A timer may be used, releasing the queue after a predetermined amount oftime since the last packet was sent through the slow tunnel has elapsed.The value of this timer may be set by controller 200, or it may be setby the access node. As an example, the access node may track the timethe last packet was sent, and the time between sending a packet throughthe slow tunnel and the arrival of an ACK from the destination, and usea value based on such transit times.

A combination of these approaches may also be used. The timer approachprovides a useful backup mechanism in the event a marked packet is lostin transit.

It should be noted that low-level responses such as ACKs are not queued,and once the peer-to-peer tunnel is established, these packets may besent through the peer-to-peer tunnel, even if queueing is in effect.

Such queueing may be bidirectional, or unidirectional. In the case of aclient receiving a video stream from a monitoring camera, an essentiallyone-way flow of data, a unidirectional approach is adequate. In the caseof a video or audio conferencing connection, for example, with audio andpossibly video streams in both directions, bidirectional queuing isappropriate.

While the invention has been described in terms of various embodiments,the invention should not be limited to only those embodiments described,but can be practiced with modification and alteration within the spiritand scope of the appended claims. The description is this to be regardedas illustrative rather than limiting.

1-18. (canceled)
 19. A non-transitory computer readable mediumcomprising instructions executed by a processor to: forward, at a firstnetwork device on a first communication path between a first networknode and a second network node, data traffic from a first client coupledto the first network node toward a second client coupled to the secondnetwork node; in response to a determination that the data traffic iseligible for a particular forwarding, instruct at least one of the firstnetwork node and the second network node to establish a secondcommunication path that does not include the first network device, fortransmitting the data traffic between the first network node and thesecond network node.
 20. The medium of claim 19, wherein the particularforwarding is peer-to-peer forwarding.
 21. The medium of claim 19,wherein the instructions are executed by the processor to: determine, atthe first network device, whether the data traffic is eligible forpeer-to-peer forwarding between the first network node and the secondnetwork node; and in response to the determination that the data trafficis not eligible, continue to forward the network traffic through thefirst communication path.
 22. The medium of claim 19, wherein a secondnetwork device is also on the first communication path, wherein thesecond communication path does not include the second network device,and wherein the first network device and the second network device arecontrollers.
 23. The medium of claim 22, wherein the first networkdevice is a first controller to manage the first network node and thesecond network device is a second controller to manage the secondnetwork node.
 24. The medium of claim 19, wherein instructions executedto determine whether the data traffic is eligible for the particularforwarding comprises instructions executed to determine whether the datatraffic is eligible for peer-to-peer forwarding based on whether a userof the first client is authorized to access the second client.
 25. Themedium of claim 22, wherein the first network device and the secondnetwork device are in a same Internet Protocol (IP) subnet.
 26. Themedium of claim 22, wherein the first network device and the secondnetwork device are in different Internet Protocol (IP) subnets.
 27. Anetwork device comprising: a processor; and memory storing instructionsexecuted by the processor to: forward, on a first communication path,data traffic from a first client coupled to a first network node towarda second client coupled to a second network node, wherein the firstcommunication path is between the first network node and the secondnetwork node that includes the network device; determine whether thedata traffic is eligible for a particular forwarding between the firstnetwork node and the second network node; and in response to adetermination that the data traffic is eligible for the particularforwarding, instruct at least one of the first network node and thesecond network node to establish a second communication path to transmitthe data traffic between the first network node and the second networknode, wherein the second communication path does not include the firstnetwork device.
 28. The network device of claim 27, wherein a secondnetwork device is on the first communication path and the secondcommunication path does not include the second network device.
 29. Thenetwork device of claim 28, wherein the first network device and thesecond network device are controllers.
 30. The network device of claim28, wherein the first network device is a first controller configured tomanage the first network node and the second network device is a secondcontroller to manage the second network node.
 31. The network device ofclaim 27, wherein to determine whether the data traffic is eligible forpeer-to-peer forwarding, the instructions are further to cause theprocessor to determine whether the data traffic is eligible forpeer-to-peer forwarding based upon whether a user of the first client isauthorized to access the second client the data traffic to the secondnetwork device via the first communication path.
 32. The network deviceof claim 28, wherein the first network device and the second networkdevice are in a same Internet Protocol (IP) subnet.
 33. The networkdevice of claim 28, wherein the first network device and the secondnetwork device are in different Internet Protocol (IP) subnets.
 34. Amethod comprising: forwarding, at a first network device on a firstcommunication path between a first network node and a second networknode, data traffic from a first client coupled to the first network nodetoward a second client coupled to the second network node, wherein thefirst network device includes a processor; determining, by theprocessor, whether the data traffic is eligible for a particularforwarding between the first network node and the second network node;in response to a determination that the data traffic is eligible for theparticular forwarding, instructing, by the processor, at least one ofthe first network node and the second network node to establish a secondcommunication path that does not include the first network device or thesecond network device, for transmitting the data traffic between thefirst network node and the second network node.
 35. The method of claim34, wherein determining whether the data traffic is eligible for theparticular forwarding comprises determining whether the data traffic iseligible for peer-to-peer forwarding based upon whether a user of thefirst client is authorized to access the second client.
 36. The methodof claim 35, wherein determining whether the data traffic is eligiblefor the particular forwarding comprises determining that the datatraffic is eligible for peer-to-peer forwarding when a user of the firstclient is authorized to access the second client without requiring thatthe network device filter the data traffic.
 37. The method of claim 34,wherein forwarding comprises forwarding the data traffic to the secondnetwork device via the first communication path.
 38. The method of claim34, wherein a second network device is also on the first communicationpath, wherein the second communication path does not include the secondnetwork device, and wherein the first network device and the secondnetwork device are in a same Internet Protocol (IP) subnet.